Digital fonts have become ubiquitous in the age of the personal computer. While the increasing availability of different fonts have concomitantly increased the range of typographic expression available when preparing document on a computer, it has created a new class of problems. In particular, a document created on one computer system using digital fonts available on that system may not be readily displayed with high fidelity on another system (even if the type of computers and/or operating systems are identical), unless the same font files are available on the other system. While it is possible for the second operating system to map a font request made by, for example, a word processing application, into a request for a related, but different font, this replacement font will not in general be a close replica of the font used to create the document on the original computer system.
Digital electronic representations of fonts are typically stored on components of the hardware that comprises the computer system, such as on a hard disk, or in a read only memory (ROM) in a printer. Fonts are then "requested" by a document that has been opened by application software, for display by the computer system. If a requested font is available, the computer operating system accesses the digital data defining the font, converts the data into native graphical display objects, and then displays the appropriate characters. If the font is not available, the operating system may attempt to substitute another available typeface.
The font creation and distribution process can be described as a sequence of operations applied to an initial artistic representation or conception of a font. The first operation, which is typically performed in the "shop" using computer software, converts from an initial visual or pictorial representation of each character in a font, to a digital format suitable for distribution to the "field." In the field, a sequence of operations is performed to display the font on a computer system, either on a computer monitor, on the output of an electronic printer, or using any other output device capable of producing a bitmap (or other type) display of one or more characters of the font. This same process is normally used to create and supply typefaces to the field, regardless of the digital format in which the font is distributed.
The basic prior art digital formats used for distributing fonts are as follows:
Bitmapped Fonts
Fonts represented as bitmaps have typically been tuned for a particular system resolution. That is, each displayed character in the font consists of a certain number of black pixels that have been laid into a square grid. Consequently, different digital bitmap files must be created for different display sizes of a given typeface. Software is available that facilitates digitally defining the shapes of bitmapped fonts, making the task of producing or modifying such fonts somewhat easier. The most significant example of such software for bitmapped fonts is the METAFONT.TM. program, designed by D. E. Knuth. The METAFONT.TM. program includes procedural software used to construct digital representations of fonts, based on numerical input data. However, the instruction stream generated by compiling a METAFONT.TM. font description source file must be executed once for each different desired point size, since the output digital font format is bitmapped. Thus, a desired point size font cannot be generated in the field using a subset of all possible input parameters, since the capability to develop the appropriate font file exists only in the shop; the binary files distributed to the field (each of which actually contains the complete character definitions for a given point size bitmapped font) are in fact much larger than the original data files used to create them; and the range of fonts that can be constructed by arbitrary selection of input parameter values is necessarily quite limited.
Scalable Outline Fonts
Fonts represented by scalable outlines are generally stored as a collection of on-curve and/or off-curve points, which describe fundamental graphical constructs such as lines and circular arcs, or second-order and third-order Bezier curves. They can be displayed accurately at nearly any device resolution. However, at low resolutions, hinting programs are usually executed prior to rasterization to improve the perceived appearance of characters in the font. Scalable font files are considerably smaller than the collection of bitmapped font files that would be required to represent the same range of point sizes for a particular typeface. Nevertheless, since all points, hint programs, and metric data are stored in the data file, the file size required to provide high fidelity replication of the original font is typically 35-70 kBytes; hence 200 such fonts would require 7-14 MB of storage for font description data alone. Commercially available examples of digitally scalable outline font formats are PostScript.TM. Type 1 and TrueType.TM. 1 (which use Bezier curves to connect points), and INTELLIFONT.TM. (which uses lines and arcs).
Generally, outline fonts based on any of these scalable formats are generated in the shop that is producing the font and then distributed to the field. The operating systems of the computers on which these fonts are used can generate the required characters by directly converting the digitally formatted font files into graphical display objects, or by using utility software provided by the font vendor, which enables the operating system to perform the conversion.
Distortable Outline Fonts
Fonts represented by distortable outlines are generally stored as one or more scalable outline fonts with rules that specify either how to extrapolate from a particular outline font, or how to interpolate between two or more outline fonts. The extrapolations and/or interpolations occur along a limited number of well-defined axes or line segments. For example, suppose that two scalable typefaces, which differ only in "contrast," are defined as the end points of an interpolation operation. (The typographic term "contrast" is defined for purposes of this discussion, as the difference between the widths of the stems or strokes used for vertical and horizontal components of the characters in the font.) The lower contrast font is assigned the value 0.0 on the "contrast" axis, while the higher contrast font is assigned the value 1.0. The rules applied to the distortable font data specify the interpolation of the on-curve and off-curve point positions, as the "contrast" parameter is varied. These rules, the two outline fonts, any hint programs, and the subsystem that applies the rules to the available outlines can be used for generating a font. The metric data and the "contrast" value constitute a digital parameter file. In principle, any value of the contrast that can be found between the two endpoints of the interpolation axis can be used to create a new font. However, since the outlines that define the endpoints of the "contrast" interval must have the same number of points, distortion cannot occur between two fonts that contain fundamentally different topologies, preventing one font from being edited by adding such distortion, to synthesize the other font having a different topology. Furthermore, other typographic characteristics, such as "weight," cannot be altered by adjusting the "contrast" parameter; hence, an additional axis and two additional outline fonts must be added to define new interpolation endpoints. This fact has very significant consequences relating to the size of the data file required to define a conventional distortable font.
In general, if n typographic characteristics are to be represented by a distortable font, then 2.sup.n outline fonts are required to define the endpoints of the necessary distortion axes, and an identical number of input parameters must be specified to produce the output font. Clearly, then, a single distortable font file cannot be provided that will generate a wide variety of fonts (with a corresponding variety of character topologies and typographic nuances) without becoming exponentially large and requiring an unacceptably long generation time. This problem is substantially compounded if additional scalable typefaces are assigned to points internal to an n-dimensional hypercube defined by the distortion axes; these intermediate typefaces are required to allow more complex interpolation rules to be defined. In practice, then, distortable typefaces implemented for a computer system with finite storage and speed can produce a large number of fonts, but only within a design space of limited dimensions, i.e., allowing only a limited number of parameters that can be varied between the different fonts that are produced.
Utility software also exists that can convert from one format to the other, and/or distort the original font character outlines. However, the results of such conversion are often poor replications of the original font.
An ideal font supply system that is capable of rendering a wide variety of digital typefaces would have distinct advantages over these prior art font creation and distribution technologies. In particular, it should satisfy three requirements: (a) it should be able to generate characters from digital font data at least as fast as a display rasterizer can display the characters on an output device; (b) the system for generating fonts and the data that define each font should occupy only a small fraction of the electronic storage space (either static or dynamic) required by the operating system; and, (c) the system for generating fonts and the data that define each font should be easily portable from one operating system to another. None of the prior art schemes for developing fonts and supplying those fonts to an end user effectively meets all of these requirements.
In addition, a font creation/generation system should be able to override the font generator execution state at any time, allowing high-fidelity font replicas (as well as original typefaces) to be produced without explicitly providing the values of all possible variables in the input parameter files. Instead, the majority of variable values should be computed from global variables or constants that are valid for all characters in the font, or are assigned unique default values in the function describing the character itself. Following this approach, only a few input parameter values would need to be stored in the binary parameter files defining a font and these files would likely be small in size, e.g., requiring less than two kBytes of hard disk storage space for each font. Again, none of the prior art has this capability.
An additional desirable feature of the font creation/generation system would be the ability to easily extend character generation instructions to include new glyph topologies. In the font generation shop, a new function containing source code describing the new font topology could then be added to the list of active font generation functions and then compiled into a binary file. In the field, a compiled glyph binary code describing an outline unique to a particular typeface should be able to read from a parameter file to make a runtime addition to the binary file defining fonts on the system.